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[57] ABSTRACT 

The present invention relates to a method and system for 
efficient image handling. The invention includes an image 
server with which image files are registered. The image 
processing requests are sent to the image server to produce 
image data representing the processed image file. In one 
embodiment of the invention, a document processing appli- 
cation obtains an image file for printing. The application 
registers the image with the image server. The image server 
returns an identifier identifying the image file which is used 
for subsequent image processing requests. The apphcation 
initiates a print job, sending the image identifier and selected 
print parameters to a printer driver. In response, the printer 
driver negotiates image processing requests with the image 
server to modify the image file in accordance with the 
selected print parameters. Finally, the processed image data 
is retrieved from the image server and sent to the printer. The 
image server and printer driver may be separate and inde- 
pendently executing processes. In an alternate embodiment, 
the application, image server and printer driver are loaded on 
two or more networked computers. 

20 Claims, 3 Drawing Sheets 
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METHOD AND APPARATUS FOR 
PROCESSING AND PRINTING DOCUMENTS 

TECHNICAL FIELD 

The present invention relates generally to processing 
documents and more specifically to a method and system for 
preparing documents for printing. 

BACKGROUND ART 

Image processing has become a commonplace activity 
due to the ease and availability of the hardware and software 
used to capture images. The popularity and accessibility of 
the Internet, and more importantly the creation of the World 
Wide Web, have greatly increased the use of images. 
However, the processing of captured images and other 
graphical elements is generally more complex as compared 
to the processing of textual data. For example, color images 
may need to be color matched between a video display and 
a printer, edge enhanced to extract certain features, and so 
on. Such manipulations tend to be CPU intensive, and 
because of the large amounts of data typically associated 
with image files, especially color images, such manipula- 
tions also tend to be I/O intensive. One area that is affected 
by the increased use of images, for example, is the prepa- 
ration and printing of documents containing such images. 

Because of the availability of sophisticated word process- 
ing and other desktop publishing programs, documents 
generally no longer consist solely of text data, but rather 
include a variety of images. Preparing such documents for 
printing on a computer may reqtiire several image process- 
ing operations including scaling, clipping, sharpening, vari- 
ous transformations and the like. These operations are 
performed either by the application or by printer driver 
software normally included with the printer. As a conse- 
quence of incorporating images into a document, the com- 
puter system will experience a high degree of loading due to 
the processing of the large amoimts of data, typical of 
graphical image elements. Several approaches to document 
preparation and printing exist. 

Some applications prepare a device independent bitmap 
of an image of the document to be printed. The bitmap is 
then sent to a printer via its corresponding printer driver 
software. In most cases, the application has no knowledge of 
the printer's requirements. For example, a user may decide 
to print a medium quality image using a certain kind of 
paper. This requires that an image of the document be 
created with a certain resolution and bit depth. The apph- 
cation cannot determine the resolution and/or bit depth 
needed to render output in accordance with the print param- 
eters selected by the user. Such knowledge is contained in 
the printer driver. The application, having to accommodate 
any kind of printer, therefore takes a conservative approach 
and sends a copy of a high resolution bitmap of the image 
to the printer driver. The printer driver then perfonms addi- 
tional processing (e.g. decimation) on the received copy of 
the high resolution image to generate output for the printer 
at the appropriate resolution. 

This simple approach is a very inefficient way of printing. 
The application always generates a high resolution copy of 
the document regardless of the printer and the selected print 
parameters. This translates to the unnecessary processing of 
large amounts of data, requiring excessive disk activity as 
intermediate files are created, written out to the disk, read in 
from the disk, processed, written back out to the disk and so 
on. Such activity adversely impacts the user since access to 
the CPU is blocked until the print job has completed. 
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In another approach, the document processing application 
queries the printer driver to determine what image process- 
ing capabilities exist in the printer driver. The application 
then decides how to divide up the image processing tasks 

5 between the application and the printer driver. The applica- 
tion produces an appropriate image of the document and 
sends a copy of the image to the printer driver. The printer 
driver performs any required additional processing on the 
copy of the received image and outputs a final printer image 
of the document to the printer. Knowing the image process- 
ing capabilities of the printer driver improves efficiency, 
since printer-specific processing such as output resolution 
generation is performed by the printer driver. The applica- 
tion no longer needs to generate a high resolution bitmap in 

23 an attempt to accommodate all printers. Rather, the appli- 
cation performs only device-independent operations such as 
clipping, red-eye correction, sharpening, etc., operations not 
typically supported by the printer driver. This results in a 
smaller image file that is then passed from the application to 

20 the driver. From the standpoint of the user, however, the 
CPU still is tied up until the application has processed the 
image and passed a copy of the image to the printer driver, 
at which point the printer driver performs additional printer- 
specific processing on the received copy of the image and 

25 outputs the generated printer image to the printer. 

To alleviate the waiting, most computers use a technique 
known as spooling to return the CPU to the user as quickly 
as possible from a print job. The printer image, i.e. the 
bitmap image that is actually sent to the printer, is copied out 

30 to the disk and sent to the printer as a background process. 
TTiis allows the printer driver to return control of the 
computer back to the user without having to wait for the 
actual output to be produced. However, transmitting the final 
printer image to ^e printer quite often represents only a 

35 small fraction of the total effort of the print job, most of the 
effort and time being expended both by the application and 
the printer driver to produce the printer image of the 
document in the first place. 

One operating system has taken the spooling technique 

40 one step further. Under the Microsoft® Windows '95 oper- 
ating system, a method known as enhanced metafile format 
(EMF) spooling was implemented. With EMF spooling, the 
operating system (OS) spools up all of the calls that the 
application makes to the printer driver to a spool file, much 

45 in the same way that a printer image is presently spooled. 
The OS then plays back the spooled file, sending the spooled 
information to the printer driver, thus completing the print 
job entirely in the background. Control of the computer is 
returned to the user sooner under EMF spooling, since the 

50 user no longer must wait for the printer driver to perform its 
image processing operations. 

Yet, even with EMF spooling, there still are factors which 
impact system performance during printing. Most notably is 
the fact that large amounts of data are being passed through 

55 the system. For example, consider a 24-bit color digitized 
image of an 8"3<10" photograph. Roughly 20 megabytes of 
data are needed to represent such an image at 300 dpi and 80 
megabytes of data at 600 dpi. With EMF spooling, the OS 
spools up the calls made to the printer driver from the 

60 application, along with a copy of the 20 or 80 megabytes of 
data that represent the image. The spooled file is written to 
disk. During playback, the spooled file (which includes the 
20 megabytes of image data) is read back from the disk and 
handed to the printer driver. As the printer driver prepares 

65 the printer image, temporary files are created, stored on the 
disk, read from the di^, written back out to the disk and so 
on. All of this disk activity takes its toll in the response time 
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and overall performance of the OS. What the user perceives application (e.g. a word processing application) to register a 

is a very slow and otherwise non-responsive system. document, the image server will lock the document to 

While the foregoing discussion has focused on the bottle- prevent other processes from accessing the document. This 

necks experienced during the processing of a print job, ensures the integrity of the document during the time the 
similar bottlenecks exist in the processing of images in 5 image server produces the desired printer image, 

general. What is needed is a method and system which Nevertheless, upon receiving a subsequent unlock request, 

minimizes the amount of data being passed by the OS during image server can make a temporary copy of the docu- 

the handling and processing of images. In particular, a °ient and unlock the original. Since the document is refer- 

method and system is needed to more efficiently process a enced by way of the identifier originally provided by the 
print job. It is also desirous to minimize the disk activity ^0 image server, processes outside of the image server are 

experienced by the OS during the processing of an image, unaffected by the copying. 

such as during a print job. In a variation of the preferred embodiment, two or more 

applications are loaded, each selecting a document to be 

SUMMARY OF THE INVENTION printed and each issuing a print job in accordance with the 

In accordance with the present invention, processing an present invention. Similarly, two or more printer drivers may 

image to produce a desired appearance of the image begins loaded and executed as separate program units. In this 

by registering the image with an image server. The image ^^X* ^^^^ ^^an one kind of printer can be supported. Each 

server returns a handle, identifying the image within the such printer driver is written or otherwise configured with 

image server. Image processing requests then are sent to the ability to communicate with its corresponding printer, 

image server in accordance with the desired appearance of In yet another variation of the preferred embodiment, the 

the image. The processed image is then retrieved from the image server and printer driver(s) may reside on two or more 

image server. networked computers. The application(s) can be co-located 

In one embodiment, a method and system for printing a with the image server or printer driver(s), or located on 

document includes registering the document with an image separate computers. This provides maximum flexibility in 

server and subsequently receiving from the image server an configuring a site having multiple workstations configured 

identifier identifying the document. The document to be around a file server and one or more printers, while at the 

printed is registered with the image server by passing to the same time realizing the performance benefits made possible 

image server a file descriptor which identifies the location of ^® present invention. 

the document. TTie file descriptor typically is the filename of gj^jgp DESCRIPTION OF THE DRAWINGS 
the document located on disk, but may be a pointer to a 

location in shared memory where the document is stored. FIG. 1 is a system diagram of an embodiment of the 

Continuing, the identifier is passed to a printer driver, along present invention, 

with print parameters describing the desired appearance of FIG. 2 illustrates a typical sequence of events when 

the printed document. Using the identifier to reference the processing documents in accordance with the present inven- 

document, the printer driver sends image processing tion. 

requests to the image server, directing the latter to form a FIG. 3 shows the interfaces between the software com- 

printer image by processing an image of the document in ponents of the system of the present invention, 

accordance with the print parameters. FinaUy. the printer nO. 4 is a system diagram of the present invention 
dnver retrieves the printer image firom the image server. ^ arranged in a networked configuration, 
which consists only of the image data of the processed 

document needed for downloading to a printer. BEST MODE FOR CARRYING OUT THE 

The amount of data being passed through the system INVENTION 

during printing is kept to a minimum. For example, rather The best mode contemplated for practicing the present 
than copying large volumes of data representing the docu- 45 invention is depicted in the system block diagram shown in 

ment from the address space of one process into the address piG. 1. In a computer system 40, one or more user appli- 

space of another process, an identifier is used instead. The cations 100, 200 generate and manipulate documents 

identifier serves to identify the document, and because it is through interactions with users. Such applications include 

an identifier of the document and not the document itself the word processing programs, drawing programs, spreadsheet 
amount of data passed is significantly less. . 50 programs, document assembly programs, photographic 

Another feature of the present invention is that only those imaging programs and the like. The term "users" is herein 

portions of the image that are needed to form the final printer defined as either a human user interacting with the 

image are accessed by the image server. In this way, the apphcation, or an automated agent which interacts with the 

amount of handling of the images contained in a document apphcation; e.g. software which emulates a fax machine 
is minimized. The result is lower disk activity for saving and 55 automatically receiving incoming faxes, image scanning 

loading data to and from the disk during the formation of the software, automated data retrieval software, etc. The appli- 

printer image. In addition, the load on the CPU is less. This cations 100, 200 have access to a data store 30 for storing 

has the overall effect of providing a quicker turnaround time and retrieving data as needed. The data store 30 further 

for the user issuing a print command and improving system includes areas within the address space of the application's 
performance. 50 random access memory (RAM), and may refer to different 

In a preferred embodiment of the present invention, the areas within shared memory, 

user application which initiates the print jobs executes An image processing server 10 provides image processing 

separately firom and independently of both the image server capability for manipulating image-containing documents, 

and the printer driver. Similariy, the image server and the The applications 100, 200 communicate with the image 
printer driver may be separate, concurrent and indepen- 65 server 10 by way of an image server interface, which is 

denlly executing processes, if the OS supports multi-tasking described in greater detail below. Like the applications, the 

operation. When the image server receives a request from an image server 10 has access to the data store 30. 
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Some of the applications 100 are showD in communica- Continuing, the application 100 receives the handle cre- 

tion with printer drivers 300, to which printing devices 22, ated by the image server and sends it and the specified print 

24 are connected. Each of the printer drivers 300 is written parameters to the printer driver 300, steps 68 and 90. The 

specificaUy for a particular type and/or kind of printer printer driver 300 then sends one or more image processing 

device. For example, the printer device 22 may be a plotter, 5 requests to the image server 10 to process the image iden- 

while the printer device 24 is a laser printer. Alternatively, ^y the handle in accordance with the print parameters, 

both printer devices 22, 24 may be inkjet printers, but fra^ step 70. Next, the printer driver retrieves the processed 

different manufacturers and each requirmg a dnver which ^ ^ata from the image server, step 72, and sends the 

can commumcate with the device. retrieved image daU to the corresponding printer 22, 24, step 

An aspect of the invention is and the prmter drivers 300 92. Finally, the document is unlocked, step 74. 

may be loaded as independently executing program units; tr ♦u • .11 r ^ 

i.e each is a separate process. Commuwcations among the '^'f ^^^^^ ^'^'^^ " ':°Py °^ '^"^'^.f V" 

processes are provided through weU known and fuUy under- '^"^"•"^.k*"""*', ^T'?^ rT 

stood interprocesscommunication (IPC) techniques, such as '^''^^f, ° local copy. The fact of the copying .s 

RFC OLE and COM. Most operating systen>s (OS) support complete y transparent to the prmter dnver smce it uses the 

at least some form of multitaddng aid also provide for IPC '^'f^ ^'''t 'u ^ "^n , T f °'P'"'"'° 

^ T ' I r\c» ' I A *u ' ^ of the prmt job, the image server will delete the local copy, 

among processes. Typical OS s mclude: the many mcama- r j » & rj 

tions of the UNIX OS; the Macintosh OS; Windows 3.x; Generally, the image server 10 provides the bulk of the 

Windows '95 and Microsoft NT. This list, of course, is i™*g® processing operations in the present invention, 

merely exemplary and not intended to be limiting. The However, it may be desirable to Umit the processing capa- 

present invention can be effectively implemented on other ^^^y ^« ^^^^^ ^^^^ ^ those generic operations which 

multitasking systems which support IPC. mdependent of any kind or type of printer. Any printer 

The flowchart shown in FIG. 2 illustrates the steps typi- ^Pf ^^8^ requirements can be performed by the printer 

cally performed when printing images and documents in ^"^^ ^P°° retnevmg the miage data m step 72 to form a 

accordance with the present invention. The sequence shown 25 ^""^^ '""'^^ '^^'''^ ^ ^° P'""^^'* 

in FIG. 2 corresponds to the applications 100 and printer ^^G. 2 includes additional steps 80 through 84, which 

drivers 300 shown in FIG. 1. First, a document is obtained address the issue of backward compatibility. Prior to regis- 

by an appUcation 100, either by reading in a file from the Bering the document with the image server 10, the applica- 

data store 30 and/or from input provided by a user of the ^^0° 1^ first queries the printer driver to determine whether 

application, step 60. The document is identified by the name 30 interface to the image server, step 80. If the 

of the file on disk, or by an address pointer in memory where response is negative, the application proceeds along the lines 

the document is stored. In addition to obtaining the of P^ior art printing methods. Typically, this means the 

document, the application 100 obtains from the user print fPpHcation produces a device independent bitmap (DIB) 

parameters describing the desired appearance of the printed i™ag^ of document to be printed and sends the DIB 

document 35 i°iage to the printer driver for subsequent printing, steps 82 

Continuing, the appUcation 100 registers the document ^: However if the printer driver siipports an image 

with the image server 10 by sending its file name, or its ^^ver mterface, then the apphcation contmues along steps 

address pointer, to the image server, step 62. Recall that the ^^^g*^ ^ ^ descnbed above, 

applications 100, 200 and the image server 10 may be 1° another embodiment, also depicted in FIG. 2, the 

independently executing processes. Each process therefore 40 method of the present invention includes only those steps 

may have its own logical address space, which generally is identified by the reference numerals 60 through 72. This 

not directly accessible by other processes. Thus, if an sequence corresponds to the applications 200 shown in FIG. 

application registers a document by way of an address 1- Th^s alternate embodiment is a generalization of the 

pointer, the document must reside in a shared memory present invention, of which the above-described printing 

region which can be accessed by two or more processes. 45 process is a special case. In the generalized method, the 

Similariy, an address pointer may be used when the data apphcation 200 itself communicates with the image server to 

exists in one address space, as in the case with dynamically effectuate desired image processing operations on the 

linked libraries. document, step 70. In addition, the resulting processed 

Upon receiving the document identifier, the image server "^^S^ ^^^^ necessarily printed, but rather may simply 

10 creates a handle which identifies the document indepen- 50 stored onto the data store 30, or displayed on a video 

dently of the identifier provided by the application 100, step terminal. 

64. Although the term "handle" typically implies certain The discussion will now tum to the components of the 

data structures, the references to ^'handle" in this application present invention. Numerous software modules comprise 

are not intended to be limited to such data structures. Rather, most of the major components of the system. As such, many 

any implementation of a "handle" consistent with the 5S existing programming languages can be used to practice the 

description given in this application is contemplated. invention; most notably the C and C++ languages. The 

Continuing, the image server then lodes the document to fiinclionsof the software modules are defined in terms of the 

prevent access to it by other applications^ step 66. The applications programmer interface (API) for each module, 

document handle and document locking mechanisms ensure specific implementation details simply being a matter of 

the integrity and consistency of the document while it is 60 producing the code to perform the operations required to 

being processed by the image server. For example, if a implement the API. In some cases, however, it may be 

second application attempts to modify the document, it must necessary to explain the operation in terais of an actual OS. 

first send an unlock request to the image server. The image Id order to provide the needed context in those cases, the 

server may respond by making a local copy of the document Windows *95 operating system environment will be used, 

and unlocking the original. The image server subsequently 65 Referring to FIG. 3, the apphcation 100 typically includes 

references the local copy, and relinquishes the original the following components: application specific code 101; 

document so that the second application may access it. printer utilities 302 for communicating with the printer 
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driver 300; I/O utilities 32 for reading and writing a memory 
store 30; and image server utilities 12 for communicating 
with the image server 10. The application specific code 101, 
of course, varies depending upon the application. As men- 
tioned above, various types of applications are 
contemplated, including word processing, drawing 
programs, spreadsheets, desktop publishing programs and so 
on. 

The printer drivers 300 include driver specific code 301 
for communicating with printing devices, and further 
include the image server utilities for communicating with 
the image server. In addition to providing a communication 
interface to the printing device, the driver specific code 301 
may perform certain image processing operations specific to 
the printer. In this way, the image server 10 needs to provide 
only those image processing operations that are device 
independent. 

The image server 10 includes the I/O utilities 32 and 
image server specific code 11 which implements image 
processing operations such as resolution scaling, image 
enlargement/reduction, clipping, red-eye correction, 
rotations, feature extraction, edge enhancement and so on. 
Such operations are known and understood by those of 
ordinary skill in the computer imaging and computer graph- 
ics arts. The image server can be designed to support one or 
more of the many types of image formats that exist in the 
industry, including but not limited to JPEG, MPEG, GIF, 
TIFF, etc. It is noted that the specific formats supported by 
the image server are not critical to the practice of the present 
invention. Rather, the choice of format(s) will depend on 
weighing certain factors such as desired capability of the 
image server, complexity of the code, complexity of the 
image formats, processing capacity, storage requirements, 
operating environment, system cost, etc. 

The I/O utilities 32 perform standard operations, includ- 
ing: open a file, close a file, read from a file and write to a 
file. Such operations are fully understood by those skilled in 
the software arts and therefore require no further elabora- 
tion. 

The printer utilities 302 enable the application 100 to 
communicate with the printer driver 300 to initiate a print 
job. Included in the printer utilities is a function which 
enables the application 100 to determine whether the printer 
driver 300 supports an image server interface, see step 80 in 
FIG. 2. Under Windows '95, for example, this may be 
accomplished by making a system call to ExtEscapeQ for 
the IS_SUPPORT code (image server support). A printer 
driver 300 which supports the image server 10 will recog- 
nize the IS_SUPPORT code and respond aflSrmatively. 
Consequently, the return value firom the call to ExtEscape 
(QUERYESCSUPPORT, IS_SUPPORT) wiU be positive. 
Otherwise, the renim value will be 0 (zero), indicating that 
the image server is not supported. 

If the image server is not supported, the apphcation will 
continue processing in the manner presently done in the 
prior art. Namely, the application will generate a DIB image 
and send the image to the printer driver 300, which under 
Windows '95 is done by making a system call to 
StretcbDIBitsQ and passing a pointer to the DIB image. On 
the other band, if the printer driver supports the image 
server, the application will obtain a handle to the image (see 
below, see also step 68 of FIG. 2) and make the system call 
to StretchDIBitsQ, passing the handle instead of the DIB 
image. 

The image server utilities 12 define the interface to the 
image server. Thus, image processing operations are effec- 



tuated by making the appropriate calls to the utilities. The 
application programmer's interfaces (API's) for the image 
server utilities will be discussed below. These API's define 
the functionality of the image server and thus obviate the 

5 need to provide examples of the source code that imple- 
ments the image server, which will depend on the OS and the 
programming language used. It is understood that a person 
of ordinary skill in the programming arts can produce the 
code which implements the functions defined by the API. 

^0 As mentioned above, the image server 10 is capable of 
supporting a variety of image formats. Since the image 
server is accessed through the image server utilities 12, the 
image server can be easily extended to support additional 
image formats as new formats are defined. The presence of 

15 the image server utilities 12 makes this extension completely 
transparent to applications/drivers which use the image 
server, thus maintaining backward compatibility when the 
image server is upgraded to support new image formats. 

FIG. 3 shows the API definitions for the image server 
utilities 12. The figure shows the utilities are divided 
between the application 100 and the printer driver 300. This 
is not necessarily the case, however. Depending on the 
particular use, all of the listed utilities may reside within one 
application, or may be divided among a number of appli- 

^ cations. In alphabetical order, the API's are: 
Closelmage 
Function: 

Informs the image server that processing of the image 
3Q file is complete. The image server will unlock the 

image file to allow access to the file by others. 
Parameters: 

IhlmageHandle — ^Identifies the image file. 
Returns: 

35 TRUE — Function was successful. 

ISE_NOTREGISTERED— ihlmageHandle does not 
map to a currently registered image file. 
Configurelmage 
Function: 

40 Informs the image server of the image processing 
operations (formatting options) to be performed on 
the image. 
Parameters: 

ihlmageHandle — Identifies the image file to be pro- 
cessed. 

ipImageProcOptions — A data structure which contains 
the requested image processing options. 
Returns: 

TRUE — ^Function was successful. 
ISE_FORMAT_NOTSUPPORTED-^pecified format 
is not supported by the image server. 
ISE_NOTREGISTERED— ihlmageHandle does not 
map to a currently registered image file. 
Openlmage 
Function: 

Informs the image server that image processing opera- 
tions are to be performed on the specified image (via 
calls to ConfigurelmageO)- 
60 Parameters: 

ihlmageHandle — Identifies the image file. 
Returns: 

TRUE — ^Function was successful. Image server is 
ready to accept image processing requests for ihlm- 
65 ageHandle. 

ISE_JVOTREGISTEREI>— ihlmageHandle does not 
map to a currently registered image file. 
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QueryFormatSupport 
Function: 

Queries the image server as to whether the image server 
supports the specified image format. Information 
may be provided indicating additional processing 
capability supported by the image server for the 
specified image format. 
Parameters: 

dwImageFormat — ^The specified image format of inter- 
est. For example, TIFF, JPEG, MPEG, GIF. 

IpFormatData — ^Pointer to a data structure indicating 
additional processing capability, e.g. compositing, 
provided by the image server. 
Returns: 

ISE__FORMAT_SUPPORTED^pecified format is 
supported by the image server. If IpFormatData is 
not the NULL pointer, then additional formatting 
features may be specified therein by the image 
server. 

ISE_FORMAT_NOTSUPPORTED^pecified for- 
mat is not supported by the image server. 
Query Image 
Function: 

Provides information about the specified image file. 
Parameters: 

ihlmageHandle — Identifies the image file for which 
information is desired. 

Iplmagelnfo— Pointer to image information data struc- 
ture. Filled in by the image server. 
Returns: 

TRUE — Function was successful. 

ISE_NOTREGISTERED— ihlmageHandle does not 
map to a currently registered image file. 
Registerlmage 
Function: 

Locks and/or copies the specified image file and returns 
a private handle to the locked/copied image file. The 
handle is used for subsequent access to the file. 

Parameters: 

IpszImageFileName — Points to a fully qualified path/ 
file name of the image file. Alternatively, the image 
file may be passed by a pointer to a buffer, in which 
case, IpszImageFileName is the NULL pointer. 

IpJobData — ^Points to a structure containing pertinent 
job data, such as the name of the print device. 

dwImageFormat — Specifies the image format of the 
specified image file. 

IpImageHandle — Points to a buffer into which the 
image handle (generated by the image server) will be 
copied. 

IpImageData — Points to a buffer containing the image 
file. Alternatively, the image file may be referenced 
by a fully qualified path/file name, in which case 
IpImageData is the NULL pointer. 

IpImageDataHeader — Points to a data structure which 
defines the format of the data pointed to by IpIm- 
ageData. 

This is the NULL pointer if IpImageData is also the 

NULL pointer. 
dwOptions — Specifies how the image is file is regis- 
tered with the image server. Valid values include: 
IS_TEMPFILE— The file pointed to by IpszImage- 
FileName is a temporary file that is to be deleted 
by the image server when a call to Closelmage is 
made. 

IS_COPYNOW— The file pointed to by IpszImage- 
FileName is a not temporary file, but the image 
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server should make a copy of the image file rather 
than locking the file. 
Returns: 

TRUE — Function was successful. IpImageHandle 

points to a valid handle (created by the image server) 

for the image. 
ISE_OUTOFSPACE— Could not make requested 

copy of image file. IpImageHandle contents are 

undefined. 

ISE_FORMNOTSUPP— Format specified in dwIm- 
ageFormat not supported by this version of the image 
server. IpImageHandle contents are undefined. 
RetrievelmageBand 

Function: 

Requests the image data of the processed image, gen- 
erated by the image server as a result of preceding 
call(s) to ConfigurelmageQ- 
Parameters: 

ihlmageHandle — ^Identifies the image file. 

XSrc — ^X-coordinate of the desired portion of the 
image data generated by the image server, in pixels. 

YSrc — ^Y-coordinate of the desired portion of the image 
data generated by the image server, in pixels. 

cxSrc — Width of the desired portion of the image data 
generated by the image server, in pixels. 

cySrc — Height of the desired portion of the image data 
generated by the image server, in pixels. 

IpBandBuffer — Pointer to a buffer in which the image 
server is to place the requested portion of the gen- 
erated image data. 

IpBandHeader — Pointer to a data stmcture which 
specifies the format of the image data to be stored in 
IpBandBuffer, 
Returns: 

TRUE — Function was successful. 
ISE_PROCERROR— Processing error encountered by 

the image server. 
ISE_NOTCONFIGURED— No processing operations 

have been performed. No calls have been made to the 

function ConfigurelmageQ. 
ISE_NOTREGISTERED— ihlmageHandle does not 

map to a currently registered image file. 
Unlocklmage 
Function: 

Removes the file lock on IpszImageFileName if the file 
is currently locked by the image server. In doing so, 
the image server will make a temporary copy of the 
image file. 
Parameters: 

IpszImageFileName — File name of the image file to be 

unlocked. 
Returns: 

TRUE — Function was successful. IpszImageFileName 
is unlocked. 

ISE_OUTOFSPACE— Could not make a copy of the 
image file in order to unlock IpszImageFileName. 
The image file remains locked by the image server. 
ISE_NOTUNLOCK— Could not unlock IpszImage- 
FileName. This typically indicates that the file was 
not locked by the image server. 
The following fragment of pseudo-code illustrates how 
the above calls might appear in a typical document-handling 
application: 
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/* is JPEG supported? •/ 
dwImageFormat < — JPEG image format 
QueryFormatSupport( dwImageFormat, IpFormatData ) 
if( return value ~ ISE_FORMAr_NOTSUPPOKrED ) 
exit 

/* register the image file */ 
IpszImagcFileName < — document fi.le name 
IpJobData < — user specified, printer options 
dwImageFormat < — JPEG image format 
IplmagcData <— NULL 
IpImagcDataHeader < — NULL 

dwOptions <— IS_COPYNOW /• do not lock the file */ 
Registerlmage ( IpszImageFileName, IpJobdata, dwImageFormat, 

IpImageHaQdle, IpImageData, IpImageDataHeader, dwOptions ) 
if( return value !- TRUE ) 

exit 

/• 

send handle (IpImageHacdle) to the printer driver, 

along with print parameters 

•/ 



The following pseudo-code fragments illustrate how the 
image server utilities might appear in the printer driver 
software: 



/* tell image server: about to start image processing */ 
ihlmagdiattdle < — image handle received from user application) 
C^enlmage( ihlmageHandle ) 
if ( return value — ISE^NOTREGISTTERED ) 

inform user application: invalid handle 

exit 

/• perform image processing •/ 

for all print parameters received from user application, do 
ipImageProcOptions < — print parameters 
Configure Image( inlmagcHaadle, ipImageProcOptions ) 
if( return value — ISE_PORMAr_NOTSUPPOKrED ) 
infonn user applicaton: invalid print parameter(s) 
exit 

continue 

/* obtain image data of the processed image and send to printer V 
XSrc < — X-coordinate of initial segment of the processed image 
YSrc < — Y'coordinate of initial segment of the processed image 
cxSrc < — width of image portion 
cySrc < — height of ima^ portion 

IpBandHeader < — retrieve the processed image in GIF format 
for all segments of the processed image data, do 

RetrieveImageBand( ihlmageHandle, Xsrc, Ysrc, 
cxSrc, cySrc, IpBand Buffer, IpBandHeader ) 

send segment pointed to by IpBandBuffcr to the printer 

increment to the next segment of the processed image 

Xsrc < — X-coordinate of next segment 

Ysrc < — Y-coordinate of next segment 
continue 



CloseImage( ihlmageHandle ) 



The discussion will now turn to an embodiment of the 
present invention depicted in FIG. 4. Whereas the compo- 
nents of the invention arc shown in FIG. 1 as residing on one 
computer, the same components shown in FIG. 4 are dis- 
tributed over two or more networked computers. The com- 
puters 42 through 48 are interconnected by a network SO. 
The network 50 may be an Ethernet backbone in a LAN 
(local area network) or may include the telephone network 
in a WAN (wide area network). More generally, the com- 
puters 42 through 48 may be interconnected by some 
combination of LAN and WAN. The present invention can 
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be practiced with any network configuration, and is not 
limited to any one architecture. 

Each computer communicates over the network via its 
network interface 52. The interface 52 includes the hardware 

S and server software needed to allow the particular computer 
to access another computer over the network. Recall that the 
applications 100, image server 10 and printer drivers 300 are 
separate processes, and that communication among these 
processes is accomplished by appropriate IPC calls. In a 

10 networked configuration, the IPC calls must be replaced 
with equivalent remote procedure calls (RPC) so that these 
processes can operate over the network. While the imple- 
mentation of RPC generally depends upon the capabilities of 
the particular OS, it nevertheless is within the scope of a 

35 person of ordinary skill in the programming arts. 

FIG. 4 shows a computer which functions as a disk server 
44. Resident on the disk server is an image server 10 of the 
present invention. Printer drivers 300' are also loaded on the 
disk server 44 to drive printers 22, 24. Another computer 48 

20 serves primarily as a printer server for printers 26, 28. User 
applications 100 residing on computer 42 can access files on 
the disk 30, via server software running on the disk server 
44. User applications 200 nmning on computer 46 operate in 
a similar manner. 

25 Although the components of the present invention are 
distributed, the operation of the invention remains the same. 
Thus, for example, a RegisterlmageQ call can be initiated 
from the application 100 on computer 42, sent across the 
network to computer 44 and processed by the image server 

30 10. The image server 10 creates a handle and returns the 
handle to the application 100. The application then commu- 
nicates over the network to initiate a print job with printer 
driver 300' on computer 44. From there, the printer driver 
300' and image server 10, operating within the same com- 

35 puter 44, interact in the manner described above to produce 
the final printer image. Altematively, the application 100 
may initiate a print job with printer driver 300" on computer 
48. Like the printer driver 300'on computer 44, the printer 
driver 300" on computer 48 negotiates image processing 

40 requests with the image server 10. However, unlike the 
printer driver 300' on computer 44, the printer driver 300" 
must negotiate the image server calls over the network. 
We claim: 

1. A method of processing images, comprising the steps 

45 of: 

(a) obtaining a digitized image; 

(b) specifying transformation parameters indicating a 
desired appearance of said digitized image; 

50 (^) registering said digitized image with an image server; 

(d) in response to said step of registering, receiving an 
image identifier handle from said image server; 

(e) sending image processing requests to said image 
server to produce image data of said digitized image in 

55 accordance with said transformation parameters, 
including sending said image identifier to said image 
server to identify said digitized image, whereby said 
desired appearance of said digitized image is produced; 
and 

60 (f) retrieving said image data from said image server. 

2. The method of claim 1 further including loading a user 
application and said image server as concurrently and inde- 
pendently executing programs on a computer, said user 
application performing said substeps (a) through (Q. 

65 3. The method of claim 1 further including loading first 
and second user apphcations on a computer, said first user 
application performing said substeps (a) through (e) for a 
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first digitized image, said second user application perform- 
ing said substeps (a) through (e) for a second digitized 
image. 

4. The method of claim 1 further including loading a user 
application on a first computer and loading said image server 
on a second computer, said user application performing said 
substeps (a) through (f). 

5. The method of claim 1 wherein said step of registering 
includes transmitting to said image server an image 
reference, said image reference indicating the location of 
said image. 

6. The method of claim 5 wherein said image reference is 
a file name if said image is disk-resident, or a beginning 
location in a random access memory (RAM) if said image is 
resident in said RAM. 

7. The method of claim 1 further including: 

loading a user application, said image server and a printer 
driver, each as a concurrently and independently 
executing program unit, said printer driver being con- 
figured to communicate with a first type of printer; 
said user application performing substeps (a) through (d); 
transmitting said image handle and said transformation 
parameters from said user application to said printer 
driver subsequent to performing said substep (d); 
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said printer driver having means for obtaining said 
manipulated image data from said image processing 
server, and further having means for transmitting said 
manipulated image data to a printer of a first kind. 

12. The system of claim 11 wherein said document 
processing application, said image processing server and 
said printer driver are resident in a single computer. 

13. The system of claim 11 further including a first 
computer for executing said document processing applica- 
tion and a second computer for executing both said image 
processing server and said printer driver, said first and 
second computers having a communication channel ther- 
ebetween. 

14. The system for claim 11 further including a first 
computer for executing said image processing server and a 
second computer for executing said printer driver, said first 
and second computers having a communication channel 
therebetween. 

15. The system of claim 11 further including a second 
printer driver, a second printer of a second kind and a 
communication channel therebetween, said means for com- 
municating job parameters including means for selecting 
between said printer driver and said second printer driver. 

16. A method of printing documents in a computer 



said printer driver performing said substeps (e) and (f); 25 system, comprising the steps of: 



and 

transmitting said image data firom said printer driver to 
said first type of printer. 

8. The method of claim 7 further including a step of 
loading a second printer driver on said computer as a 
concxurently and independently executing program, said 
second printer driver being configured to communicate with 
a second type of printer. 

9. The method of claim 7 further including loading a user 
application on a first computer and loading said image server 
and said printer driver on a second computer. 

10. The method of claim 7 further including load|ing and 
executing said image server of a first computer and loading 
and executing said printer driver on a second computer. 

11. A system for printing documents from a document 
processing application, said system including: 

a first memory store containing a plurality of documents, 
said documents having document locators which 
specify the location of said documents in said first 
memory store; 

an image processing server; and 

a printer driver; 

said image processing server being an independently 
executing program unit; 

said image processing server having means for generating 
a document identifier upon receipt of a document 
locator, said document identifier identifying the docu- 
ment specified by said document locator; 

means for initiating a print job, including means for 55 
communicating one of said document locators to said 
image processing server, means for obtaining a corre- 
sponding document identifier £rom said image process- 
ing server and means for communicating job param- 
eters to said printer driver, said job parameters go 
including print parameters and said corresponding 
document identifier; 

said printer driver having means for manipulating image 
data of the document identified by said corresponding 
document identifier, including means for sending 
image processing requests to said image processing 
server in accordance with said print parameters; 
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loading into random access memory (RAM) of said 

computer system a first user application; 
loading into said RAM a document server process and 
executing said document server process concurrently 
with and independently of said first user application; 
loading into said RAM a printer driver process and 
executing said printer driver process concurrently with 
and independently of said first user application and said 
document server process; 
with said first user application, selecting a first document 
to be printed and specifying first print parameters 
indicating a desired appearance of said first document, 
said first document having a first document identifier 
used to access said first document; 
from said first user application, communicating said first 
document identifier to said document server process, 
followed by a substep of communicating a first docu- 
ment handle from said document server process to said 
first user application; 
from said first user application, issuing a print job includ- 
ing communicating said first document handle and said 
first print parameters to said printer driver process; 
from said printer driver process and using said first 
document handle, communicating image processing 
requests to said document server process in accordance 
with said print parameters, so that image data of said 
desired appearance of said first document is generated 
by said document server process; 
from said document server process, communicating said 

image data to said printer driver process; and 
from said printer driver process, communicating said 
image data to one of a printer and a storage device for 
subsequent printing. 
17. The method of claim 16 further including the steps of: 
loading into said RAM a second user application; 
with said second user application, selecting a second 
document to be printed and specifying second print 
parameters, said second document having a second 
document identifier; 
from said second user application, communicating said 
second document identifier to said document server 
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process, followed by a step of communicating a second 
document handle from said document server process to 
said second user application; and 
from said second user application, communicating said 
second document handle and said second print param- 
eters to said printer driver process. 

18. The method of claim 16 further including loading into 
said RAM a second printer driver process, said first user 
application selectively communicating said first document 
handle and said first print parameters to one of said printer 
driver and said second printer driver. 

19. The method of claim 16 further including locking said 
first document so that said first document is accessible only 
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by said document server process, said substep of locking 
being performed in response to receipt of said first document 
identifier by said document server process. 
20. The method of claim 19 further including a step of 

S accessing said first document subsequent to said step of 
issuing a print job, said step of accessing including request- 
ing said document server process to unlock said first 
document, creating a temporary copy of said first document 
and unlocking said first document, whereby said first user 

^0 application has access to said first document and said 
document server process accesses said temporary copy. 

* * If * * 
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